In graphics image processing systems, application of texture maps to the surfaces of graphics primitives are used to create the appearance of texture on a rendered graphics image. Texture maps are typically graphics images composed of “texels” that are arranged in a rectangular coordinate system. Thus, a texture map has an associated width and height. In applying the texture map to the surface of a graphics primitive, the texel coordinates of texels that are needed to calculate the color value of a pixel in a rendered graphics image are identified, and the color data associated with the identified texels are retrieved from memory. The color value of the pixel is then calculated from the retrieved color values using one of various well-known techniques. Consequently, when a texture map is applied to the surface, the surface adopts the characteristics of the texture, such that the coloring for the surface is derived from the texture. The applied texture map results in a realistic texture appearance in the rendered graphics image.
Prevailing computer graphics application program interfaces (APIs), such as OpenGL and Direct3D, have long supported a technique called “mipmapping.” MIP stands for multim in parvum or “many in few.” Mipmapping is a process by which graphics applications dynamically can trade off rendering speed for texture image detail. The underlying idea is that distant objects do not need to be rendered at the same level of detail (LOD) as objects that are close. To this end, a graphics processing system may use variations of the same texture map at different resolutions or sizes for objects located at different distances from the viewer.
As one would imagine, there are various considerations in deciding the LOD in mipmapping operations. For example, the distance of the object (or its size) is one parameter. Another consideration is the size of the texture image being applied. When these parameters are considered together, the LOD calculation can be reduced to a relationship between pixels and texels. That is, if one pixel step (in screen coordinates) is equal to one texel step (in texture coordinates) then the ratio is 1-to-1 and the LOD is log2(1/1) or zero. If one pixel step is equal to a two texel step, than the ratio is 2-to-1 and LOD is equal to log2(2/1) or one. For a four texel step per pixel, LOD is equal to log2(4/1) or two.
Although LOD computations such as those previously described are conceptually simple, hardware implementation of the same is typically cumbersome because the computations involve complex calculations, such as texture coordinate gradients, two-function derivatives, base-two logarithm conversion, and the like. As previously illustrated, solving the base-two logarithm is an integral part of this computation. However, the base-two logarithm computation is particularly cumbersome because of the cost of implementing the computation in hardware. One approach to the base-two logarithm computation is the use of a table lookup with predetermined locked to values stored in each table entry. Another approach is the use of piece-wise linear functions with tables storing the parameters for the various sections of linear approximations. More complex alternatives use second-order (or higher) polynomial approximations for ranges of input, typically using fewer table entries, each holding more parameters than the linear versions. These approaches have been proven and can be designed for desired error characteristics. However, the conventional approaches typically consume a relatively large amount of space for implementation. Where the graphics processing system is implemented on a single device, or where space in a single device is at a premium, the aforementioned conventional approaches may not be acceptable alternatives.
Therefore, there is a need for an area efficient method and apparatus for performing level-of-detail computations.